Hacker's Arsenal - The Cutting Edge of Hacking

home *** CD-ROM | disk | FTP | other *** search

/ Hacker's Arsenal - The Cutting Edge of Hacking / Hacker's Arsenal - The Cutting Edge of Hacking.iso / texts / misc / ifws.txt < prev next >

Wrap

Text File | 2001-07-11 | 22.1 KB | 558 lines

Internet Firewalls Frequently Asked Questions ============================================= About the FAQ ============= This FAQ is not an advertisement or endorsement for any product, company, or consultant. The maintainer welcomes input and comments on the contents of this FAQ. Comments related to the FAQ should be addressed to Fwalls-FAQ@tis.com. The FAQ is also available via WWW from http://www.tis.com Contents: ========= 1: What is a network firewall? 2: Why would I want a firewall? 3: What can a firewall protect against? 4: What can't a firewall protect against? 5: What are good sources of print information on firewalls? 6: Where can I get more information on firewalls on the network? 7: What are some commercial products or consultants who sell/service firewalls? 8: What are some of the basic design decisions in a firewall? 9: What are proxy servers and how do they work? 10: What are some cheap packet screening tools? 11: What are some reasonable filtering rules for my Cisco? 12: How do I make DNS work with a firewall? 13: How do I make FTP work through my firewall? 14: How do I make Telnet work through my firewall? 15: How do I make Finger and whois work through my firewall? 16: How do I make gopher, archie, and other services work through my firewall? 17: What are the issues about X-Window through a firewall? 18: What is source routed traffic and why is it a threat? 19: What are ICMP redirects and redirect bombs? 20: Glossary of firewall related terms ------------------------------ Date: Mon Jun 27 15:50:11 1994 From: Fwalls-FAQ@tis.com Subject: 1: What is a network firewall? A firewall is any one of several ways of protecting one network from another untrusted network. The actual mechanism whereby this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one which exists to block traffic, and the other which exists to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traffic. ------------------------------ Date: Mon Jun 27 15:50:28 1994 From: Fwalls-FAQ@tis.com Subject: 2: Why would I want a firewall? The Internet, like any other society, is plagued with the kind of jerks who enjoy the electronic equivalent of writing on other people's walls with spraypaint, tearing their mailboxes off, or just sitting in the street blowing their car horns. Some people try to get real work done over the Internet, and others have sensitive or proprietary data they must protect. A firewall's purpose is to keep the jerks out of your network while still letting you get your job done. Many traditional-style corporations and data centers have computing security policies and practices that must be adhered to. In a case where a company's policies dictate how data must be protected, a firewall is very important, since it is the embodiment of the corporate policy. Frequently, the hardest part of hooking to the Internet, if you're a large company, is not justifying the expense or effort, but convincing management that it's safe to do so. A firewall provides not only real security - it often plays an important role as a security blanket for management. Lastly, a firewall can act as your corporate "ambassador" to the Internet. Many corporations use their firewall systems as a place to store public information about corporate products and services, files to download, bug-fixes, and so forth. Several of these systems have become important parts of the Internet service structure (e.g.: UUnet.uu.net, gatekeeper.dec.com) and have reflected well on their corporate sponsors. ------------------------------ Date: Mon Jun 27 15:50:35 1994 From: Fwalls-FAQ@tis.com Subject: 3: What can a firewall protect against? Some firewalls permit only Email traffic through them, thereby protecting the network against any attacks other than attacks against the Email service. Other firewalls provide less strict protections, and block services that are known to be problems. Generally, firewalls are configured to protect against unauthenticated interactive logins from the "outside" world. This, more than anything, helps prevent vandals from logging into machines on your network. More elaborate firewalls block traffic from the outside to the inside, but permit users on the inside to communicate freely with the outside. The firewall can protect you against any type of network borne attack if you unplug it. Firewalls are also important since they can provide a single "choke point" where security and audit can be imposed. Unlike in a situation where a computer system is being attacked by someone dialing in with a modem, the firewall can act as an effective "phone tap" and tracing tool. ------------------------------ Date: Mon Jun 27 15:50:48 1994 From: Fwalls-FAQ@tis.com Subject: 4: What can't a firewall protect against? Firewalls can't protect against attacks that don't go through the firewall. Many corporations that connect to the Internet are very concerned about proprietary data leaking out of the company through that route. Unfortunately for those concerned, a magnetic tape can just as effectively be used to export data. Firewall policies must be realistic, and reflect the level of security in the entire network. For example, a site with top secret or classified data doesn't need a firewall at all: they shouldn't be hooking up to the internet in the first place, or the systems with the really secret data should be isolated from the rest of the corporate network. Firewalls can't protect very well against things like viruses. There are too many ways of encoding binary files for transfer over networks, and too many different architectures and viruses to try to search for them all. In other words, a firewall cannot replace security- consciousness on the part of your users. In general, a firewall cannot protect against a data-driven attack -- attacks in which something is mailed or copied to an internal host where it is then executed. This form of attack has occurred in the past against various versions of Sendmail. ------------------------------ Date: Wed Jul 6 14:45:13 1994 From: Fwalls-FAQ@tis.com Subject: 5: What are good sources of print information on firewalls? There are several books that touch on firewalls. The best known are: Title: Firewalls and Internet Security: Repelling the Wily Hacker Authors: Bill Cheswick and Steve Bellovin Publisher: Addison Wesley Edition: 1994 ISBN: 0-201-63357-4 Title: Practical Unix Security Authors: Simson Garfinkel and Gene Spafford Publisher: O'Reilly Edition: 1991 ISBN: 0-937175-72-2 (discusses primarily host security) Related references are: Titles: Internetworking with TCP/IP Vols I, II and III Authors: Douglas Comer and David Stevens Publisher: Prentice-Hall Edition: 1991 ISBN: 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (III) Comment: A detailed discussion on the architecture and implementation of the Internet and its protocols. Vol I (on principles, protocols and architecture) is readable by everyone, Vol 2 (on design, implementation and internals) is more technical, and Vol 3 (on client-server computing) is recently out. Title: Unix System Security - A Guide for Users and System Administrators Author: David Curry Publisher: Addision Wesley Edition: 1992 ISBN: 0-201-56327-4 ------------------------------ Date: Mon Jun 27 15:54:03 1994 From: Fwalls-FAQ@tis.com Subject: 6: Where can I get more information on firewalls on the network? Ftp.greatcircle.com - Firewalls mailing list archives. Directory: pub/firewalls Ftp.tis.com - Internet firewall toolkit and papers. Directory: pub/firewalls Research.att.com - Papers on firewalls and breakins. Directory: dist/internet_security Net.Tamu.edu - Texas AMU security tools. Directory: pub/security/TAMU The internet firewalls mailing list is a forum for firewall administrators and implementors. To subscribe to Firewalls, send "subscribe firewalls" in the body of a message (not on the "Subject:" line) to "Majordomo@GreatCircle.COM". Archives of past Firewalls postings are available for anonymous FTP from ftp.greatcircle.com in pub/firewalls/archive ------------------------------ Date: Fri May 5 09:34:43 1995 From: Fwalls-FAQ@tis.com Subject: 7: What are some commercial products or consultants who sell/service firewalls? We feel this topic is too sensitive to address in a FAQ, however, an independantly maintained list (no warrantee or recommendations are implied) can be found at URL: http://www.access.digex.net/~bdboyle/firewall.vendor.html ------------------------------ Date: Mon Jun 27 15:54:23 1994 From: Fwalls-FAQ@tis.com Subject: 8: What are some of the basic design decisions in a firewall? There are a number of basic design issues that should be addressed by the lucky person who has been tasked with the responsibility of designing, specifying, and implementing or overseeing the installation of a firewall. The first and most important is reflects the policy of how your company or organization wants to operate the system: is the firewall in place to explicitly deny all services except those critical to the mission of connecting to the net, or is the firewall in place to provide a metered and audited method of "queuing" access in a non-threatening manner. There are degrees of paranoia between these positions; the final stance of your firewall may be more the result of a political than an engineering decision. The second is: what level of monitoring, redundancy, and control do you want? Having established the acceptable risk level (e.g.: how paranoid you are) by resolving the first issue, you can form a checklist of what should be monitored, permitted, and denied. In other words, you start by figuring out your overall objectives, and then combine a needs analysis with a risk assessment, and sort the almost always conflicting requirements out into a laundry list that specifies what you plan to implement. The third issue is financial. We can't address this one here in anything but vague terms, but it's important to try to quantify any proposed solutions in terms of how much it will cost either to buy or to implement. For example, a complete firewall product may cost between $100,000 at the high end, and free at the low end. The free option, of doing some fancy configuring on a Cisco or similar router will cost nothing but staff time and cups of coffee. Implementing a high end firewall from scratch might cost several man- months, which may equate to $30,000 worth of staff salary and benefits. The systems management overhead is also a consideration. Building a home-brew is fine, but it's important to build it so that it doesn't require constant and expensive fiddling-with. It's important, in other words, to evaluate firewalls not only in terms of what they cost now, but continuing costs such as support. On the technical side, there are a couple of decisions to make, based on the fact that for all practical purposes what we are talking about is a static traffic routing service placed between the network service provider's router and your internal network. The traffic routing service may be implemented at an IP level via something like screening rules in a router, or at an application level via proxy gateways and services. The decision to make here is whether to place an exposed stripped-down machine on the outside network to run proxy services for telnet, ftp, news, etc., or whether to set up a screening router as a filter, permitting communication with one or more internal machines. There are plusses and minuses to both approaches, with the proxy machine providing a greater level of audit and potentially security in return for increased cost in configuration and a decrease in the level of service that may be provided (since a proxy needs to be developed for each desired service). The old trade-off between ease-of-use and security comes back to haunt us with a vengeance. ------------------------------ Date: Mon Jun 27 15:54:30 1994 From: Fwalls-FAQ@tis.com Subject: 9: What are proxy servers and how do they work? A proxy server (sometimes referred to as an application gateway or forwarder) is an application that mediates traffic between a protected network and the Internet. Proxies are often used instead of router-based traffic controls, to prevent traffic from passing directly between networks. Many proxies contain extra logging or support for user authentication. Since proxies must "understand" the application protocol being used, they can also implement protocol specific security (e.g., an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP). Proxy servers are application specific. In order to support a new protocol via a proxy, a proxy must be developed for it. SOCKS is a generic proxy system that can be compiled into a client-side application to make it work through a firewall. Its advantage is that it's easy to use, but it doesn't support the addition of authentication hooks or protocol specific logging. For more information on SOCKS, see ftp.nec.com: /pub/security/socks.cstc Users are encouraged to check the file "FILES" for a description of the directory's contents. ------------------------------ Date: Mon Mar 13 10:21:02 1995 From: Fwalls-FAQ@tis.com Subject: 10: What are some cheap packet screening tools? The Texas AMU security tools include software for implementing screening routers (FTP net.tamu.edu, pub/security/TAMU). Karlbridge is a PC-based screening router kit ( ftp://ftp.net.ohio-state.edu/pub/kbridge [US] ftp://ftp.gbnet.net/pub/kbridge [UK/Europe] http://www.gbnet.net/kbridge/ gopher://gopher.gbnet.net/ ). A version of the Digital Equipment Corporation "screend" kernel screening software is available for BSD/386, NetBSD, and BSDI. Many commercial routers support screening of various forms. ------------------------------ Date: Fri May 5 11:16:26 1995 From: Fwalls-FAQ@tis.com Subject: 11: What are some reasonable filtering rules for my Cisco? The following example shows one possible configuration for using the Cisco as a filtering router. It is a sample that shows the implementation of a specific policy. Your policy will undoubtedly vary. In this example, a company has Class B network address of 128.88.0.0 and is using 8 bits for subnets. The Internet connection is on the "red" subnet 128.88.254.0. All other subnets are considered trusted or "blue" subnets. +---------------+ +---------------+ | IP provider | | Gateway | | 128.88.254.1 | | 128.88.254.2 | +------+--------+ +------+--------+ | "Red" net ----------+-----------------+---------------------------------- | +------+--------+ | Cisco | | 128.88.254.3 | |...............| | 128.88.1.1 | +---------------+ | ----------------------------+---------------------------------- | "Blue" net +------+--------+ | mail router | | 128.88.1.2 | +---------------+ Keeping the following points in mind will help in understanding the configuration fragments: 1. In these rules the Ciscos are applying filtering to output packets only. 2. Rules are tested in order and stop when the first match is found. 3. There is an implicit deny rule at the end of an access list that denies everything. The example below concentrates on the filtering parts of a configuration. Line numbers and formatting have been added for readability. The policy to be implemented is: Anything not explicitly allowed is denied Traffic between the external gateway machine and blue net hosts is allowed. Permit services orginating from the blue net Allow a range of ports for FTP data connections back to the blue net. 1 no ip source-route 2 ! 3 interface Ethernet 0 4 ip address 128.88.1.1 255.255.255.0 5 ip access-group 10 6 ! 7 interface Ethernet 1 8 ip address 128.88.254.3 255.255.255.0 9 ip access-group 11 10 ! 11 access-list 10 permit ip 128.88.254.2 0.0.0.0 128.88.0.0 0.0.255.255 12 access-list 10 deny tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 lt 1025 13 access-list 10 deny tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 gt 4999 14 access-list 10 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 15 ! 16 access-list 11 permit ip 128.88.0.0 0.0.255.255 128.88.254.2 0.0.0.0 17 access-list 11 deny tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 25 18 access-list 11 permit tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255 Lines Explanation 1 Although this is not a filtering rule, it is good to include here. 5 Ethernet 0 is on the red net. Extended access list 10 will be applied to output on this interface. You can also think of output from the red net as input on the blue net. 9 Ethernet 1 is on the blue net. Extended access list 11 will be applied to output on this interface. 11 Allow all traffic from the gateway machine to the blue net. 12-14 Allow connections originating from the red net that come in between ports 1024 and 5000. This is to allow ftp data connections back into the blue net. 5000 was chosen as the upper limit as it is where OpenView starts. Note: again, we are assuming this is acceptable for the given policy. There is no way to tell a Cisco to filter on source port. Newer versions of the Cisco firmware will apparently support source port filtering. Since the rules are tested until the first match we must use this rather obtuse syntax. 16 Allow all blue net packets to the gateway machine. 17 Deny SMTP (tcp port 25) mail to the red net. 18 Allow all other TCP traffic to the red net. Cisco.Com has an archive of examples for building firewalls using Cisco routers, available for FTP from: ftp.cisco.com in /pub/acl-examples.tar.Z Newer revisions of the Cisco firmware (starting at 9.21) allow the administrator to specify packet filtering on inbound or outbound packets. ------------------------------ Date: Mon Jun 27 16:00:08 1994 From: Fwalls-FAQ@tis.com Subject: 12: How do I make DNS work with a firewall? Some organizations want to hide DNS names from the outside. Many experts disagree as to whether or not hiding DNS names is worthwhile, but if site/corporate policy mandates hiding domain names, this is one approach that is known to work. This approach is one of many, and is useful for organizations that wish to hide their host names from the Internet. The success of this approach lies on the fact that DNS clients on a machine don't have to talk to a DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and there are often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine. First, you set up a DNS server on the bastion host that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the "public" server. Then, you set up a DNS server on an internal machine. This server also claims to be authoritiative for your domains; unlike the public server, this one is telling the truth. This is your "normal" nameserver, into which you put all your "normal" DNS stuff. You also set this server up to forward queries that it can't resolve to the public server (using a "forwarders" line in /etc/named.boot on a UNIX machine, for example). Finally, you set up all your DNS clients (the /etc/resolv.conf file on a UNIX box, for instance), including the ones on the machine with the public server, to use the internal server. This is the key. An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the "restricted" answer from the public server. This approach assumes that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but otherwise restricts DNS between other hosts. Another trick that's useful in this scheme is to employ wildcard PTR records in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non- public hosts to return something like "unknown.YOUR.DOMAIN" rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. This may fail when talking to sites that do a DNS cross-check in which the host name is matched against its address and vice versa. Note that hiding names in the DNS doesn't address the problem of host names "leaking" out in mail headers, news articles, etc. ------------------------------ Date: Mon Jun 27 16:00:17 1994 From: Fwalls-FAQ@tis.com Subject: 13: How do I make FTP work through my firewall? Generally, making FTP work through the firewall is done either using a proxy server or by permitting incoming connections to the network at a restricted port range, and otherwise restricting incoming connections using something like "established" screening rules. The FTP client is then modified to bind the data port to a port within that range. This entails being able to modify the FTP client application on internal hosts. A different approach is to use the FTP "PASV" option to indicate that the remote FTP server should permit the client to initiate connections. The PASV approach assumes that the FTP server on the remote system supports that operation. (See RFC1579 for more information) Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library.